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I.  Introduction 

The  underlying  objective  of  the  Rome  Air  Development  Center 
Associative  Processor  (RADCAP)  Project  is  to  investigate 
solutions  to  data  processing  problems  which  strain  conventional 
approaches  due  to  high  data  rates  and  heavy  processing 
requirements.  One  example  of  this  type  of  problem  is  that  class 
of  processing  represented  by  radar  tracking  of  airborne  targets 
with  attendant  display  processing  and  formatting,  weapons 
assignment,  and  weapons  direction  functions.  A prime  example  of 
this  class  of  problems  and  the  one  chosen  for  investigation  is 
the  Airborne  Warning  and  Control  System  (AWACS,  now  designated 
the  E-3A) . The  reason  for  this  choice  was  the  fact  that  it 
represented  a "real-world"  system  and  the  results  obtained  were 
potentially  more  valid  than  results  from  hypothetical  situations. 
It  was  never  intended,  however,  to  supplant  the  AWACS  data 
processing  system  with  a processor  based  on  the  results  of  this 
investigation.  The  purpose  of  the  investigation  was  to 
demonstrate  a concept  for  advanced  processing  rather  than  to 
solve  a particular  problem. 

The  data  processing  solution  proposed  for  such  systems,  and 
the  one  under  investigation  in  this  project,  is  associative 
processing.  Associative  processing  could  be  defined  as  the 
processing  of  data  which  is  accessed  by  specifying  contents  of 
words  (or  parts  of  words)  in  memory  instead  of  location.  An 
associative  processor  is  a processor,  usually  involving  a large 
amount  of  parallel  activity,  which  is  specifically  designed  to  do 
associative  processing.  Perhaps  associative  processing  is  best 
illustrated  by  an  example.  Suppose  there  is  a theater  full  of 
people  and  you  want  to  determine  who  of  those  have  red  hair.  One 
way  to  approach  the  problem  would  be  to  go  seat  by  seat  and  note 
whether  the  person  in  that  seat  has  red  hair.  This  is  a typical 
sequential  search.  The  associative  approach  would  be  to  ask  all 
those  with  red  hair  to  stand.  It  is  obvious  that  this  method  will 
in  general  be  faster,  but  it  is  also  obvious  that  it  requires  a 
new  approach  to  the  solution  of  data  processing  problems.  The 
exact  implementation  medium  used  on  the  project  is  a Goodyear 
Aerospace  Corporation  S-1000P  Staran  Associative  Processor, 
interfaced  to  the  Honeywell  Information  Systems  HIS-645  general 
purpose  machine  running  the  MULTICS  operating  system.  This 
HIS-645  was  later  upgraded  to  a HIS-6180  running  the  MULTICS 
operating  system.  A more  detailed  description  of  the  Staran  may 
be  found  in  [11,12].  The  concept  of  the  problem  decomposition 
was  to  implement  those  functions  which  were  inherently  sequential 
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on  the  HIS-645  and  to  off-load  those  functions  which  could  more 
effectively  be  done  in  parallel  onto  the  Staran,  and  thus 
demonstrate  the  effectiveness  of  the  sequential/associative 
combination. 

This  report  describes  the  results  of  the  five  year  RADCAP 
Project.  The  report  is  organized  mostly  chronologically  with  a 
brief  narrative  background  section  first,  giving  the  events 
leading  up  to  the  conception  of  the  project.  This  is  followed  by 
short  descriptions  of  the  efforts  undertaken  and  their  results. 
These  results  are  then  brought  to  bear  on  the  problem  of  defining 
the  key  characteristics  of  an  associative  processor  to  handle 
this  class  of  problem.  The  conclusion  considers  the  applicability 
of  associative/parallel  processing  to  real-world,  real-time 
processing  problems,  and  our  view  of  the  future  of  this  type  of 
processing. 

II.  Background 

The  RADCAP  Project  was  preceded  by  the  work  done  by  RADC  in 
the  area  of  associative  memories.  This  work  and  the  benefits 
offered  by  associative  memories  opened  up  possibilities 
concerning  the  applicability  of  associative  processing  to  Air 
Force  data  processing  problems.  One  of  these  possibilities  which 
was  of  interest  is  that  which  encompasses  many  functions, 
including  tracking  and  surveillance,  found  in  typical  Air  Force 
Command  and  Control  systems.  One  example  of  such  a system  is  the 
AWACS.  It  was  felt  that  associative  processing  could  offer  the 
advantages  of  an  overall  cost  effectiveness  greater  than  that 
offered  by  a conventional  processor.  In  addition,  the  associative 
processor  offered  several  potential  benefits  in  terms  of  reducing 
the  number  of  special  purpose  signal  processing  computers  and 
reduced  weight  and  volume  for  the  main  processor  itself  in  such 
systems.  These  estimations  led  to  a proposed  advanced 
development  program  for  associative  processing  at  RADC,  designed 
to  investigate  these  potentialities. 

The  proposed  associative  processor  (AP)  program  was  reviewed 
by  the  Information  Processing  Panel  of  the  Air  Force  Scientific 
Advisory  Board  (SAB)  in  June  of  1971.  Out  of  the  proposed 
development  program  and  the  recommendations  made  by  the  SAB  grew 
the  actual  RADCAP  Project.  The  three  primary  objectives  of  the 
project  were  to: 
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a.  Assess  the  capability  of  associative  processing 
techniques  on  real-world,  real-time  applications. 

b.  Assess  the  capability  of  an  associative  processor  to 
function  efficiently  with  a host  sequential  processor. 

c.  Interact  with  a real  Air  Force  problem  in  order  to  permit 
end  user  evaluation. 

In  addition  to  the  primary  objectives  defined  above,  the 
study  had  another  goal,  that  of  the  production  of  what  the  SAB 
called  desirable  end  products.  These  were  identified  as: 

a.  Establishment  of  an  associative  processor  test  bed 

b.  Documented  software  covering  test  applications 

c.  Documents  covering  interfacing  problems,  evaluation 
results,  design  specifications  for  an  advanced  processor 
including  justification,  and  actual  reliability  test  data 

d.  Actual  USAF  in-house  expertise* 

The  major  actions  planned  to  accomplish  these  objectives  and 
obtain  the  end  products  were  to: 

a.  Buy  an  available  associative  processor  and  connect  it  to 
the  Honeywell  Information  Systems  645-MULTICS  computet  at 
RADC. 

b.  Investigate  the  feasibility  of  associative  processing  to 
handle  problems  such  as: 

1.  Radar  data  conversion 

2.  Track  correlation 

3.  Tracking 

4.  Message  formatting  (display  and  communications) 

5.  Automatic  initiatiqn  of  tracks 

6.  Weapon  assignment 

7.  Weapon  direction 

8.  Identification. 

In  addition  to  these  investigations,  there  was  to  be  an  emphasis 
on  the  publication  of  our  results  with  the  idea  that  we  consider 
sponsoring  symposia  and  meetings  of  people  from  government, 
industry,  and  the  academic  community. 

The  RADCAP  Project  was  officially  approved  in  September  of 
1971,  and  the  purchase  of  an  associative  processor  was  started. 
In  July  of  1973,  the  Goodyear  Aerospace  Corporation  Staran 
S-1000P  was  accepted  at  RADC  and  interfaced  to  the  HIS-645  (11] . 


with  the  delivery  of  the  Staran,  actual  work  on  the  AWACS 
functions  started.  The  next  portion  of  this  report  will  cover 
the  in-house  and  contract  efforts.  These  are  arranged  in  mostly 
chronological  order,  based  on  completion  date,  except  where  an 
effort  is  a logical  follow  on  from  a previous  one. 

III.  Studies 

A.  Boeing  Computer  Services  Contract  1 

The  first  study,  which  was  completed  in  September  of  1974, 
was  a contract  with  Boeing  Computer  Services.  This  was  an 
initial  study  of  some  of  the  AWACS  functions  and  the 
applicability  of  the  associative  processor  for  their  execution. 
[1]  The  functions  specifically  considered  were  passive  tracking, 
the  radar  data  correlator,  and  weapons  assignment  and  control. 
Passive  tracking  is  tracking  based  on  received  electromagnetic 
radiation  without  a radar  signal  being  sent  from  the  station 
doing  the  tracking.  This  is  the  mode  which  occurs  when  the 
target  is  sending  jamming  signals  for  the  main  radar,  in 
addition,  the  study  included  the  gathering  of  performance  data 
for  a sequential  version  of  the  active  tracking  program.  Active 
tracking  is  the  non-jamming  case  of  radar  tracking.  This 
included  timing  information  from  runs  on  an  IBM  360/65  (the 
commercial  version  of  the  AWACS  data  processor) . The  parallel 
versions  of  these  same  algorithms  were  to  be  implemented  in-house 
on  the  Staran.  Because  of  that,  identical  input  test  data  was 
obtained  for  the  parallel  version. 

In  addition  to  the  data,  this  study  produced  several 
conclusions  concerning  the  functions  studied.  Passive  tracking 
was  determined  to  be  a feasible  AP  function  and  the  passive 
tracking  algorithms  were  coded.  For  the  radar  data  correlator,,  it 
was  determined  that  only  the  signal  processing  portion  was 
inherently  parallel.  Finally,  an  analysis  of  the  weapons 
assignment  and  control  algorithms  showed  that  these  were  highly 
individual  in  each  case,  sequential  in  nature,  and  that  to 
develop  new,  parallel  algorithms  would  be  very  costly.  Since  the 
data  for  the  active  tracking  was  given  highest  priority,  the 
implementation  of  the  passive  tracking  and  the  radar  data 
correlator  was  not  completed.  This  lead  to  a follow  on  contract 
to  do  the  actual  implementation. 


B.  Boeing  Computer  Services  Contract  2 

The  second  Boeing  Computer  Services  contract  was  completed 
in  April  of  1976.  The  objectives  of  this  contract  were  to 
implement  and  measure  the  performance  of  passive  tracking, 
coordinate  conversion  and  the  radar  data  correlator  on  the 
Staran.  [2]  The  passive  tracking  was  fully  implemented  and  timed. 
However,  due  to  lack  of  funds,  timing  studies  on  the  coordinate 
conversion  were  not  completed,  and  the  radar  data  correlator  was 
not  implemented. 

The  passive  tracking  implementation  was  based  on  tracking  64 
targets  in  three  modes.  Mode  0 is  defined  as  cooperative  passive 
tracking,  i.e.,  targets  are  tracked  based  on  reports  from  two 
AWACS  aircraft.  Mode  1 is  self  passive  tracking  performed  by  a 
single  AWACS  aircraft,  and  mode  2 is  active  tracking.  Active 
tracking  differs  from  the  passive  tracking  in  that  the  returned 
reports  on  which  the  tracking  is  based  contain  explicit  range 
information,  while  in  the  passive  mode,  the  reports  contain  range 
information  only  in  the  form  of  a strobe  width. 

The  64  targets  were  tracked  for  60  scans  which  represents  10 
minutes  worth  of  data  in  the  AWACS  environment.  One  of  the 
significant  aspects  of  the  implementation  has  to  do  with  the  data 
representation  within  the  program  itself.  The  data  is,  in 
general,  represented  in  floating  point  notation.  Since  the 
arithmetic  within  the  Staran  is  bit  slice  arithmetic,  all 
arithmetic  has  to  be  done  in  software.  For  floating  point,  the 
software  becomes  much  more  complex  and  represents  a significant 
penalty  in  terms  of  control  memory  space  used  for  instructions 
and  time  for  execution  of  those  instructions.  The  trade-off, 
obviously,  is  the  ease  of  programming  that  the  floating  point 
representation  gives  you.  The  programmer  does  not  have  to  worry 
about  the  location  of  the  radix  point  as  he  does  in  fixed  point 
representation.  In  spite  of  the  penalties  involved  with  the 
floating  point  implementation,  the  passive  tracking  program  was 
able  to  achieve  crossover  points  of  21  tracks  (mode  0 and  mode  2) 
and  19  tracks  (mode  1).  Crossover  points,  as  used  in  this 
context,  are  those  points  in  terms  of  the  capacity  of  the 
program,  beyond  which  the  parallel  implementation  will  perform 
better  (i.e.  faster)  than  the  serial  version.  That  is,  for 
tracking  anything  more  than  about  20  tracks,  the  Staran  operated 
faster  than  the  IBM  360/65,  which  is  the  commercial  version  of 
the  AWACS  machine.  On  a qualitative  basis,  the  track  positions 
calculated  by  the  serial  and  parallel  versions  had  a 
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of  less  than  1%  in  most  tracks. 


discrepancy,  after  60  scans. 

The  coordinate  conversion  implementation  was  designed  to 
perform  the  functions  of  correlating  radar  data  with  navigation 
data,  and  then  convert  this  data  to  the  Command  and  Control 
Coordinate  System  (CCCS)  for  use  by  the  tracking  algorithms. 
This  involves  conversions  among  and  between  four  different 
coordinate  systems  used  in  AWACS . The  coordinate  conversion, 
unlike  the  passive  tracking,  used  fixed  point  representation  of 
the  data.  The  implementation  was  tested  with  a set  of  128 
different  reports  (both  navigational  and  radar)  . The  parallel 
version  was  timed  and  this  timing  was  compared  with  estimated 
times  for  comparable  IBM  360/65  execution.  The  net  result  was 
that  the  parallel  version  executed  about  6.7  times  faster  than 
the  estimated  execution  for  the  sequential  case. 

The  radar  data  correlator  (RDC)  performs  the  function  of 
processing  the  raw  pulse  doppler  radar  returns  for  AWACS.  The 
operations  performed  on  the  data  include  removal  of  range 
ambiguity  and  report  correlation.  The  current  AWACS  design 
incorporates  special  purpose  hardware  and  a three  CPU 
state-of-the-art  digital  computer  with  semiconductor  memory  to 
accomplish  these  tasks.  In  addition,  the  AWACS  RDC,  which  is 
designed  to  run  behind  real  time,  will  obviously  run  later  as  the 
number  of  returns  gets  very  large.  The  parallel  version  of  the 
RDC,  although  not  implemented,  was  designed  for  maximum 
processing  speed  with  the  intention  of  running  10B  milliseconds 
behind  real  time  regardless  of  the  number  of  targets  (the  bound 
on  the  AP  is  the  array  memory  capacity) . 

The  parallel  design  showed  that  a parallel  approach  to  the 
problem  could  result  in  an  improved  approach  to  the  RDC  function. 
The  proposed  design  provided  increased  radar  capability  in  terms 
of  PRF  flexibility,  reduced  processing  time,  and  improved  radar 
perfbrmance  through  a new  deghosting  algorithm  which  runs  in  real 
time  and  increases  probability  of  detection.  This  means  that  the 
parallel  implementation,  in  addition  to  providing  a faster 
solution  which  is  programmable  (and  hence  more  flexible  than 
hardwired  units)  , also  showed  promise  in  actually  improving  radar 
performance  in  terms  of  the  tracking  functions. 

The  sum  of  the  two  Boeing  Computer  Services  contracts  showed 
that  the  AWACS  functions  of  passive  tracking,  coordinate 
conversion  and  radar  data  correlation  were  amenable  to  parallel 
solutions  with  improved  capability  in  all  the  functions.  We 


would  be  amiss  in  not  noting  however,  that  the  implementations 
described  were  not  without  their  limitations.  The  passive 
tracking,  because  of  the  floating  point  representation  problem, 
required  four  Staran  arrays  (256  by  256  bits  each)  to  process  64 
tracks  of  data.  Projections  of  the  results  to  very  high  density 
environments  points  to  the  requirement  for  a large  number  of 
arrays,  representing  a very  sizable  machine.  The  coordinate 
conversion,  on  the  other  hand,  required  only  two  arrays  to 
process  64  tracks  and  for  a high  density  environment,  this 
projects  to  a reasonable,  although  still  fairly  large,  machine. 
An  alternative  to  that  size  machine,  is  to  repeat  the  algorithm 
several  times  thus  cutting  down  on  the  amount  of  array  memory 
required.  This  is  a reasonable  trade  off  based  on  the  fact  that 
the  parallel  implementation  is  so  much  faster  than  the  sequential 
implementation.  The  radar  data  correlator  initial  design  is 
based  on  arrays  which  are  twice  as  big  as  the  current  Staran 
array  but  redesign  for  smaller  arrays  is  a simple  matter.  It 
should  be  noted  at  this  point  that  the  array  space  required  in 
these  implementations  is  primarily  dependent  on  the 
representation  of  the  variables  within  the  array  and  the  space 
necessary  for  the  storage  of  history  or  intermediate  variables. 
The  limitations  described  above  are  not  based  on  processing  power 
but  on  storage  limitations  within  the  arrays  themselves.  This 
points  to  the  need  for  some  kind  of  intermediate  results  storage 
for  this  type  of  application. 


Having  laid  out  the  limitations,  the  bottom  line  result  is 
that  the  functions  studied  can  be  reasonably  done  on  an 
associative/parallel  processor  with  a demonstrable  improvement  in 
performance.  This  means  that  associative/parallel  processing 
represents  a highly  viable  alternative  to  this  class  of  data 
processing  problems. 


C.  In-house  Active  Tracking 

The  third  effort  in  the  AP  project  was  an  in-house  study 
and  implementation  of  the  AWACS  active  tracking  function.  The 
actual  implementation  dealt  with  a development  active  tracking 
program  called  ITAS  (Integrated  Tracking  and  Surveillance)  rather 
than  the  actual  AWACS  programs,  which  were  classified.  The  ITAS 
program  is  similar  to  the  AWACS  algorithms  and  implementation  of 
it  represents  a valid  attempt  at  AWACS  like  functions.  This 
effort  was  completed  in  September  of  1975.  [3] 


The  ITAS  implementation  represents  tracking  of  50  targets  for  60 
scans  (ten  minutes)  using  a Kalman  Filter  tracking  algorithm. 
The  results  of  the  implementation  were  compared  with  comparable 
runs  using  identical  input  data  on  an  IBM  360/65,  the  results  for 
which  were  obtained  from  the  first  Boeing  Computer  Services 
contract.  One  significant  aspect  of  the  active  tracking 
implementation  was  the  simulation  of  a mass  backup  storage  device 
available  for  parallel  load  (bit  slice  mode)  into  the  array. 
Three  of  the  four  arrays  on  the  RADCAP  Staran  were  used  to 
represent  this  backup,  and  all  calculations  were  done  in  a single 
array.  This  means  that  a backup  of  256  by  768  bits  was 
simulated.  Using  this  simulation,  the  implementation  was  able  to 
track  64  tracks  in  one  fourth  the  space  that  the  passive  tracking 
implementation  required.  The  difference  would  have  been  even  more 
significant  had  a larger  backup  storage  device  been  available. 

The  timing  in  the  parallel  implementation  was  linearly 
dependent  on  the  number  of  tracks  as  opposed  to  the  sequential 
case  of  dependence  on  the  number  of  reports  times  the  number  of 
tracks.  Based  on  this,  the  timing  studies  showed  a crossover 
point  of  about  25  tracks.  Even  allowing  for  optimization  of  the 
sequential  program,  the  report  concluded  that  "In  the  time 
required  by  a fully  optomized  sequential  program  to  process  200 
tracks,  the  AP  could  process  over  1000  tracks."  [3]  Even  more 
significant  was  the  fact  that  the  parallel  approach  to  the 
problem  involved  a partial  redesign  of  the  algorithm  used  in  one 
section  of  the  program.  This  redesign  provided  significant 
execution  time  savings  in  the  parallel  case,  and  more 
importantly,  implementing  that  redesign  in  the  sequential  version 
also  provided  significant  improvement  in  the  sequential  execution 
speed. 

D.  In-house  Automatic  Track  Initiation 

The  follow  on  effort  to  the  active  tracking  project  outlined 
above  involved  the  implementation  of  a function  not  currently 
performed  by  the  AWACS,  that  of  automatic  track  initiation.  This 
is  the  process  whereby  the  computer  makes  the  decision  of  whether 
to  track  a specific  target  based  on  the  history  of  the  returns  of 
that  target.  This  removes  the  requirement  for  operator 
intervention  in  order  to  get  a new  track  started.  The  rationale 
behind  this  type  of  process  comes  from  the  fact  that  an  operator 
can  handle  more  tracks  in  a given  environment  with  automatic 
track  initiation  than  he  could  using  purely  manual  techniques. 
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The  basic  result  from  this  implementation  is  that  the  extra 
time  required  to  perform  this  function  is  dependent  solely  on  the 
number  of  false  alarms  which  are  returned.  Coupling  this  result 
in  with  the  radar  data  correlator  conclusions  that  an  AP  solution 
can  give  you  qualitatively  better  data  from  the  radar,  the 
combination  of  the  two  functions  on  an  associative/parallel 
processor  becomes  a very  attractive  alternative. 

E.  In-house  Display  Processing 

The  final  effort  on  the  RADCAP  project  is  an  ongoing 
investigation  aimed  at  determining  the  applicability  of  an  AP  to 
display  processing  functions.  This  effort  is  a low  level  effort 
based  on  some  minimal  display  capabilities  in  existence  at  the 
RADCAP  facility,  but  some  algorithms  have  been  developed  and  the 
viability  of  the  AP  to  this  task  has  been  demonstrated. 

IV.  Results  of  Studies 

A.  Key  AP  Characteristics 

One  of  the  primary  results  of  the  studies  outlined  has  been 
the  identification  of  key  AP  characteristics  for  doing  an  AWACS 
type  problem.  Since  the  Staran  was  the  implementation  medium,  the 
discussion  that  follows  will  address  key  AP  characteristics 
basically  in  terms  of  those  identified  as  necessary  and  not 
possessed  by  the  Staran. 

The  first  characteristic  identified  as  necessary  was 
proposed  early  in  the  program  based  on  some  studies  by  Dr. 
Tse-yun  Feng  of  Syracuse  University.  An  initial  paper  published 
in  the  1972  Sagamore  Conference  discussed  algorithms  for  doing 
the  fast  Fourier  transform,  weather  prediction  and  matrix 
operations  on  an  associative  processor.  [4]  The  necessity  was 
shown  for  a data  manipulator  for  improving  the  processing  time 
and  saving  memory  storage  space.  A data  manipulator  in  an 
associative/parallel  processor  represents  the  parallel  version  of 
functions  like  the  shifts  and  masks  in  the  sequential  computer. 
Common  parallel  data  manipulating  functions  are  permutations, 
replications,  and  masking.  The  primary  difference  between  the 
sequential  data  manipulating  functions  and  the 
associative/parallel  functions  is  the  fact  that  the  sequential 
version  works  on  only  one  word  at  a time,  and  the  functions 
available  are  very  limited.  The  first  report  was  followed  by  a 
second  which  considered  specifically  the  data  manipulating 


functions  which  were  necessary  in  a parallel  processor  in  order 
to  handle  the  variety  of  problems  which  were  possible  on  a 
parallel  processor.  [5] 

The  logical  next  step  in  this  definition  process  was  the 
design  of  a prototype  data  manipulator.  This  was  described  in  a 
third  report  by  Dr.  Feng.  [6]  The  device  described  in  that  report 
was  implemented  in  a scaled  down  version  by  W.  W.  Gaertner 
Research,  Inc.  and  delivered  to  the  RADCAP  facility  in  September 
of  1976,  where  it  is  undergoing  test. 

The  second  desirable  characteristic  was  also  identified 
early  in  the  program.  Based  on  the  problem  of  moving  data  into 
and  out  of  the  associative  arrays,  and  the  need  for  rapidly 
moving  large  blocks  of  data  in  that  fashion,  a mass  backup  memory 
for  the  arrays  was  postulated.  This  memory  would  be  capable  of 
parallel  {bit  slice)  loading  of  the  arrays  and  could  store 
interim  results  and  other  necessary  data.  The  size  of  this  memory 
was  estimated  to  be  about  1 Gbit  (10  to  the  ninth  bits) . The  use 
of  such  a memory  would  allow  the  use  of  the  large  processing 
power  of  the  AP  without  the  problem  that  can  arise  of  becoming 
I/O  bound  in  terms  of  loading  and  unloading  the  arrays. 

Based  on  this  postulate,  a study  of  the  design  of  such  a 
mass  memory  was  initiated  with  Westinghouse  Electric  Corporation. 
The  purpose  of  the  study  was  "to  definitively  identify  the 
organizational  design  philosophies  most  suitable  to  a reasonably 
priced,  ruggedized,  random  access  1 Gbit  mass  memory  which  is 
directly  compatible  with  the  speed/bandwidth  capabilities  of  an 
associative  type  computer  processor".  [7]  The  result  was  a 
design,  based  on  MNOS  integrated  circuit  technology,  oriented 
specifically  to  interfacing  to  Staran  but  also  adaptable  to  other 
single  instruction  stream  - multiple  data  stream  (SIMD)  machines. 

The  concept  of  a large  backup  memory  was  simulated  in  the 
active  tracking  program  implementation  with  favorable  results. 
Based  on  that  simulation,  the  calculations  required  for  up  to  64 
tracks  can  be  performed  in  an  array  the  size  of  a single  Staran 
array.  A larger  backup  than  that  simulated  would  allow  for 
processing  of  more  than  that  number  for  one  array.  The  backup  is 
used  to  store  immediate  results  and  hence,  the  amount  of  high 
cost  array  memory  is  reduced. 

The  third  key  AP  characteristic  is  a well  defined,  high 
speed  interface  to  a host  sequential  computer.  The  AP,  working 
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in  a stand  alone  mode,  while  capable  of  doing  some  good  things, 
is  less  than  optimal.  In  use  the  AP  should  be  driven  be  a modern, 
high  speed  sequential  computer  capable  of  handling  the  sequential 
portions  of  the  problem,  and  off-loading  the  parallel  portions  to 
the  AP.  This  type  of  interface  was  in  the  original  plans  for  the 
RADCAP  facility  and  the  Staran  has  been  interfaced  to  the  MULTICS 
system.  However,  the  two  systems  dictated  an  awkward,  slow 
handshaking  type  of  interface.  In  light  of  this  relationship, 
and  taking  into  account  some  investigations  into  the  feasibility 
of  associative  processing  to  some  specific  applications,  we 
instituted  a study  of  the  desirable  characteristics  of  the 
AP/sequential  interface,  addressing  specifically  the  Staran  and  a 
Univac  1108.  The  study  was  performed  by  E.  B.  Wagstaff  and  R.  M. 
Watts  of  Georgia  Institute  of  Technology,  and  Frederic  J.  Mowle 
and  David  Meyer  of  Purdue  University.  [8]  The  study  considered 
alternative  ways  of  interfacing  the  Staran  to  the  1108  and  the 
limitations  of  each  way.  The  final  conclusion  was  that  the 
interface  was  feasible  using  the  1108  as  a host  if  the 
application  was  structured  in  such  a way  that  the  Staran  is 
compute  bound.  That  is,  the  interface  would  not  be  an  asset  in 
those  cases  where  data  to  be  transferred  was  operated  on  by  the 
Staran  for  less  than  10  milliseconds.  This  would  result  in  the 
situation  where  the  Staran  would  be  sitting  idle  much  of  the  time 
waiting  for  data,  and  the  interface  could  become  a bottleneck. 
This  amplifies  the  I/O  problem  with  an  associative/parallel 
processor  and  again  points  up  the  need  for  a large  mass  memory. 
It  also  clearly  identifies  the  fact  that  a Staran-like  processor 
is  valuable  primarily  in  compute  bound  problems  rather  than  I/O 
bound  problems,  and  even  tends  to  magnify  those  I/O  problems. 

The  final  key  AP  characteristic  comes  in  the  area  of 
computer  support.  To  program  a machine  like  the  Staran  using  the 
current  state-of-the-art  in  programming  languages,  dictates  that 
that  programming  must  be  done  in  assembly  language.  There  doesn't 
exist  a high  order  language  for  expressing  an  algorithm  on  an 
associative/parallel  computer.  Because  of  this,  we  instituted  a 
study  with  Goodyear  Aerospace  Corp.  to  develop  a proposed 
specification  for  a high  order  language  which  would  allow  the 
programmer  to  express  his  problem  in  a form  that  would  take 
advantage  of  the  Staran  architecture.  That  language  should  be 
applicable  to  not  only  the  Staran,  but  also  to  a wider  range  of 
highly  associative/parallel  architectures.  To  avoid  duplication 
of  past  efforts  in  this  area,  the  study  included  assessments  of 
languages  like  parallel  Pascal,  PFOUR  (PEPE) , IVTRAN  (ILLIAC-IV) , 
and  the  like.  This  effort  has  just  been  completed  and  the 
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specification  has  not,  as  yet,  been  published. 

B.  Publicizing  of  Efforts 

One  of  the  most  important  aspects  of  the  RADCAP  project  is 
that  of  disseminating  the  results  of  the  efforts  undertaken. 
Toward  this  end,  in  1972,  RADC  co-sponsored  with  Syracuse 
University,  a conference  titled  the  "1972  Sagamore  Computer 
Conference  on  RADCAP  and  its  Applications".  This  conference 
covered  the  plans  of  the  RADCAP  project  and  addressed  some 
applications  of  associative/parallel  processing.  The  attendance 
at  this  conference  was  mixed  with  about  one  third  each  from 
government,  universities,  and  the  commercial  sector.  That  kind 
of  mix  was  beneficial  for  mutual  exchange  of  information 
concerning  the  status  of  associative/parallel  processing  and  its 
potential  application  in  the  "real  world".  The  conference  was 
continued  by  Syracuse  University  in  succeeding  years  until 
sponsorship  was  taken  over  in  1976  by  Wayne  State  University  and 
the  IEEE  Computer  Society,  and  the  Sagamore  Computer  Conference 
became  the  International  Conference  on  Parallel  Processing. 
Although  RADC  was  not  a co-sponsor  of  the  conference  after  the 
first  one,  at  least  one  session  in  each  conference  has  been 
devoted  to  the  RADCAP  work  and  our  results. 

Through  these  conferences,  a total  of  34  papers  have  been 
published  in  the  last  4 years  by  RADC  personnel  and  contractors. 
We  have  also  published  six  technical  reports  on  our  work. 
These  papers  and  reports  are  listed  in  Appendix  A. 

V.  Conclusions 

A.  Accomplishment  of  RADCAP  Projedt 

The  RADCAP  Project  has  accomplished  most  the  results  that 
were  intended.  We  have  assessed  the  capability  of  AP  techniques 
on  a specific  real  world,  real  time  application  and  found  that 
for  the  largest  part  of  the  application,  the  associative 
processor  provides  a highly  capable  solution.  In  accomplishing 
this  we  have  produced  an  AP  test  bed  facility,  documented 
software  covering  the  test  applications,  documentation  covering 
results,  problems  encountered  and  potential  solutions,  and 
perhaps  most  important  of  all,  we  have  developed  a strong 
in-house  expertise  in  associative/parallel  processing.  Based  on 
that  expertise  and  our  experiences,  some  general  comments  about 
associative/parallel  processing  are  in  order. 


-12- 


The  most  important  consideration  in  associative/parallel 
processing  and  its  application  to  real  world  problems  is  that  it 
is  not  a panacea.  Some  problems  are  inherently  parallel  (for 
example  tracking  of  radar  reports) , while  others  are  inherently 
sequential  (for  example  weapons  assignment  and  direction) . We 
find  that  even  within  those  problems  that  are  inherently  parallel 
in  nature  that  there  exist  portions  that  are  sequential.  In 
addition  to  not  fitting  all  classes  of  problems, 
associative/parallel  processing,  while  solving  some  problems,  in 
itself  can  create  some  problems.  Not  the  least  of  these  are  the 
I/O  speed  and  high  order  language  issues.  The  mix  of  parallel  and 
sequential  portions  of  the  same  problem  point  out  the  necessity 
of  a sequential/parallel  system,  most  probably  a standard 
sequential  computer  as  a host  to  an  associative/parallel 
computer.  This  in  turn  implies  a good  sequential  to  parallel 
interface  in  terms  of  communication  and  input/output.  This  is 
lacking  in  the  RADCAP  facility,  and  it  is  noticable  in  its 
absence.  With  all  those  factors  taken  into  account,  however,  the 
RADCAP  Project  has  shown  that  an  associative/parallel  system  can 
provide  a very  cost  effective  solution  to  at  least  one  highly 
significant  class  of  processing  problems. 

The  second  general  conclusion  to  be  made  concerning 
associative/parallel  processing  is  demonstrated  in  the  results  of 
the  in-house  work  on  the  ITAS  program.  That  is,  the  opportunity 
for  the  programmer  to  think  of  a parallel  solution  to  the  problem 
allowed  him  to  create  a solution  which  would  have  been  rejected 
by  the  average  sequential  programmer  but  which,  when  it  was 
implemented  in  the  sequential  case,  improved  the  execution  time 
of  the  sequential  version  as  well  as  the  parallel  version.  The 
techniques  which  are  possible  with  parallel  processors  can  in 
some  cases  have  just  as  great  an  impact  on  sequential  processing. 

The  third  general  conclusion  to  be  made  about 
associative/parallel  processing  is  that  it  provides  fast 
processing.  It  does  not  make  sense  to  even  consider  this  type  of 
processing  in  cases  where  the  application  is  I/O  bound.  To 
operate  effectively,  input  to  and  output  from  an 
associative/parallel  processor  must  be  considered  carefully.  The 
necessity  for  a high  bandwidth  memory  is  apparent.  The 
usefulness  and  necessity  for  a mass  backup  store  has  been  clearly 
demonstrated.  With  these  two  attributes,  associative/parallel 
processing  can  have  significant  impact  on  processing  problems 
which  are  inherently  parallel  in  nature,  and  compute  bound  in 
operation. 
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B.  The  Future  of  Associative/Parallel  Processing 

The  future  of  associative  and  parallel  systems  where  the 
speed  of  computation  is  a factor  seems  assured  based  on  two 
separate  developments.  The  first  development  is  that  sequential 
systems  are  approaching  the  physical  limit  on  the  speed  of  logic. 
This  limit  and  the  growing  need  for  computing  power  are  forcing 
the  system  designer  to  turn  to  parallel  solutions.  This  means 
that  associative  and  SIND  type  machines  will  have  a real  place  in 
the  scheme  of  things  in  the  future.  The  second  development 
forcing  this  type  of  solution  is  the  advent  of  large  scale 
integration  (LSI)  and  the  dramatic  drop  in  hardware  prices.  LSI 
building  blocks  are  on  a large  enough  scale  to  make  building 
block  design  a practical  thing,  and  the  cost  makes  parallel 
solutions,  which  were  rejected  in  the  past  as  too  expensive,  more 
cost  effective.  No  longer  will  the  system  designer  be  concerned 
with  increasing  the  utilization  of  the  hardware  to  the  maximum 
extent  possible. 
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